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Abstract 


This document describes a protocol and new DNS Resource Record that provides a cryptographic 
message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest 
data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to 
verify the zone contents for data integrity and origin authenticity. This provides assurance that 
received zone data matches published data, regardless of how the zone data has been 
transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, 
guarding only against unintentional changes. 


ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine 
granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by 
authoritative name servers, recursive name servers, or any other applications. 


As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and 
resources required for digest calculation. However, the ZONEMD record is extensible so that new 
digest schemes may be added in the future to support large, dynamic zones. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8976. 
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1. Introduction 


In the DNS, a zone is the collection of authoritative resource records (RRs) sharing a common 
origin ([RFC8499]). Zones are often stored as files in the so-called "master file format" 
([RFC1034]). Zones are generally distributed among name servers using the zone transfer (AXFR) 
([RFC5936]) and incremental zone transfer (IXFR) ([RFC1995]) protocols. They can also be 
distributed outside of the DNS with any file transfer protocol such as FTP, HTTP, and rsync, or 
even as email attachments. Currently, there is no standard way to compute a hash or message 
digest for a stand-alone zone. 


This document specifies an RR type that provides a cryptographic message digest of the data in a 
zone. It allows a receiver of the zone to verify the zone's integrity and authenticity when used in 
combination with DNSSEC. The digest RR is a part of the zone itself, allowing verification of the 
zone, no matter how it is transmitted. The digest uses the wire format of zone data in a canonical 
ordering. Thus, it is independent of presentation format such as whitespace, capitalization, and 
comments. 


This specification is OPTIONAL to implement by both publishers and consumers of zone data. 


1.1. Motivation 


The primary motivation for this protocol enhancement is the desire to verify the data integrity 
and origin authenticity of a stand-alone zone, regardless of how it is transmitted. A consumer of 
zone data should be able to verify that it is as published by the zone operator. 


Note, however, that integrity and authenticity can only be assured when the zone is signed. 
DNSSEC provides three strong security guarantees relevant to this protocol: 


1. whether or not to expect DNSSEC records in the zone, 
2. whether or not to expect a ZONEMD record in a signed zone, and 
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3. whether or not the ZONEMD record has been altered since it was signed. 


A secondary motivation is to provide the equivalent of a checksum, allowing a zone recipient to 
check for unintended changes and operational errors such as accidental truncation. 


1.2. Alternative Approaches 


One approach to preventing data tampering and corruption is to secure the distribution channel. 
The DNS has a number of features that are already used for channel security. Perhaps the most 
widely used is DNS transaction signatures (TSIGs) ([RFC8945]). A TSIG uses shared secret keys 
and a message digest to protect individual query and response messages. It is generally used to 
authenticate and validate UPDATE ([RFC2136]), AXFR ([RFC5936]), and IXFR ([RFC1995]) 
messages. 


DNS Request and Transaction Signatures (SIG(0)) ([RFC2931]) is another protocol extension that 
authenticates individual DNS transactions. Whereas SIG records normally cover specific RR 
types, SIG(0) is used to sign an entire DNS message. Unlike TSIG, SIG(0) uses public key 
cryptography rather than shared secrets. 


The Transport Layer Security protocol suite also provides channel security. The DPRIVE Working 
Group is in the process of specifying DNS Zone Transfer-over-TLS ([DPRIVE-XFR-OVER-TLS]). One 
can also easily imagine the distribution of zones over HTTPS-enabled web servers as well as DNS- 
over-HTTPS ([RFC8484]). 


Unfortunately, the protections provided by these channel security techniques are (in practice) 
ephemeral and are not retained after the data transfer is complete. They ensure that the client 
receives the data from the expected server and that the data sent by the server is not modified 
during transmission. However, they do not guarantee that the server transmits the data as 
originally published and do not provide any methods to verify data that is read after 
transmission is complete. For example, a name server loading saved zone data upon restart 
cannot guarantee that the on-disk data has not been modified. Such modification could be the 
result of an accidental corruption of the file or perhaps an incomplete saving of the file ([DISK- 
FULL-FAILURE)). For these reasons, it is preferable to protect the integrity of the data itself. 


Why not simply rely on DNSSEC, which provides certain data security guarantees? For zones that 
are signed, a recipient could validate all of the signed RRsets. Additionally, denial-of-existence 
records prove that RRsets have not been added or removed. However, delegations (non-apex NS 
records) are not signed by DNSSEC and neither are any glue records. ZONEMD protects the 
integrity of delegation, glue, and other records that are not otherwise covered by DNSSEC. 
Furthermore, zones that employ NSEC3 with Opt-Out ([RFC5155]) are susceptible to the removal 
or addition of names between the signed nodes. Whereas DNSSEC primarily protects consumers 
of DNS response messages, this protocol protects consumers of zones. 


There are existing tools and protocols that provide data security, such as OpenPGP ([RFC4880]) 
and S/MIME ([RFC8551]). In fact, the internic.net site publishes Pretty Good Privacy (PGP) 
signatures alongside the root zone and other files available there. However, this is a detached 
signature with no strong association to the corresponding zone file other than its timestamp. 
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Attached signatures are of course possible, but these necessarily change the format of the file 
being distributed; a zone signed with OpenPGP or S/MIME no longer looks like a DNS zone and 
could not directly be loaded into a name server. Once loaded, the signature data is lost, so it 
cannot be further propagated. 


It seems the desire for data security in DNS zones was envisioned as far back as 1997. [RFC2065] 
is an obsoleted specification of the first generation DNSSEC Security Extensions. It describes a 
zone transfer signature, identified as the AXFR SIG, which is similar to the technique proposed by 
this document. That is, it proposes ordering all (signed) RRsets in a zone, hashing their contents, 
and then signing the zone hash. The AXFR SIG is described only for use during zone transfers. It 
did not postulate the need to validate zone data distributed outside of the DNS. Furthermore, its 
successor, [RFC2535], omits the AXFR SIG while at the same time introducing an IXFR SIG. (Note: 
RFC 2535 was obsoleted by [RFC4033], [RFC4034], and [RFC4035].) 


1.3. Design Overview 


This document specifies a new Resource Record type to convey a message digest of the content of 
a zone. The digest is calculated at the time of zone publication. If the zone is signed with DNSSEC, 
any modifications of the digest can be detected. The procedures for digest calculation and 
DNSSEC signing are similar. Both require data to be processed in a well-defined order and 
format. It may be possible to perform DNSSEC signing and digest calculation in parallel. 


The zone digest is designed to be used on zones that have infrequent updates. As specified 
herein, the digest is recalculated over the entire zone content each time the zone is updated. This 
specification does not provide an efficient mechanism for updating the digest on incremental 
updates of zone data. It is, however, extensible so that future schemes may be defined to support 
efficient incremental digest updates. 


It is expected that verification of a zone digest will be implemented in name server software. 
That is, a name server can verify the zone data it was given and refuse to serve a zone that fails 
verification. For signed zones, the name server needs a trust anchor to perform DNSSEC 
validation. For signed non-root zones, the name server may need to send queries to validate a 
chain of trust. Digest verification could also be performed externally. 


1.4. Use Cases 
1.4.1. Root Zone 


The root zone ([InterNIC]) is one of the most widely distributed DNS zones on the Internet, 
served by more than 1000 separate instances ([ROOT-SERVERS]) at the time of this writing. 
Additionally, many organizations configure their own name servers to serve the root zone locally. 
Reasons for doing so include privacy and reduced access time. [RFC8806] describes one way to do 
this. As the root zone spreads beyond its traditional deployment boundaries, the verification of 
the completeness of the zone contents becomes more important. 
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1.4.2. Providers, Secondaries, and Anycast 


Since its very early days, the developers of the DNS recognized the importance of secondary 
name servers and service diversity. However, modern DNS service has complex provisioning that 
includes multiple third-party providers ([RFC8901]) and hundreds of anycast instances 
([RFC3258]). Instead of a simple primary-to-secondary zone distribution system, today it is 
possible to have multiple levels, multiple parties, and multiple protocols involved in the 
distribution of zone data. This complexity introduces new places for problems to arise. The zone 
digest protects the integrity of data that flows through such systems. 


1.4.3. Response Policy Zones 


A Response Policy Zone (RPZ) is "а mechanism to introduce a customized policy in Domain Name 
System servers, so that recursive resolvers return possibly modified results" ([RPZ]). The policy 
information is carried inside specially constructed DNS zones. A number of companies provide 
RPZ feeds, which are consumed by name server and firewall products. While RPZs can be signed 
with DNSSEC, the data is not queried directly and would not be subject to DNSSEC validation. 


1.4.4. Centralized Zone Data Service 


ICANN operates the Centralized Zone Data Service ([CZDS]), which is a repository of top-level 
domain zone files. Users that have been granted access are then able to download zone data. 
Adding a zone digest to these would provide CZDS users with assurances that the data has not 
been modified between origination and retrieval. Note that ZONEMD could be added to zone 
data supplied to CZDS without requiring it to be present in the zone data served by production 
name servers, since the digest is inherently attached to the specific copy of the zone. 


1.4.5. General Purpose Comparison Check 


Since the zone digest calculation does not depend on presentation format, it could be used to 
compare multiple copies of a zone received from different sources, or copies generated by 
different processes. In this case, it serves as a checksum and can be useful even for unsigned 
zones. 


1.5. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


The terms Private Use, Reserved, Unassigned, and Specification Required are to be interpreted as 
defined in [RFC8126]. 
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2. The ZONEMD Resource Record 


This section describes the ZONEMD Resource Record, including its fields, wire format, and 
presentation format. The Type value for the ZONEMD RR is 63. The ZONEMD RR is class 
independent. The RDATA of the resource record consists of four fields: Serial, Scheme, Hash 
Algorithm, and Digest. 


2.1. Non-apex ZONEMD Records 


This document specifies ZONEMD RRs located at the zone apex. Non-apex ZONEMD RRs are not 
forbidden, but have no meaning in this specification. Non-apex ZONEMD RRs MUST NOT be used 
for verification. 


During digest calculation, non-apex ZONEMD RRs are treated as ordinary RRs. They are digested 
as is, and the RR is not replaced by a placeholder RR. 


Unless explicitly stated otherwise, "ZONEMD" always refers to apex records throughout this 
document. 


2.2. ZONEMD RDATA Wire Format 


The ZONEMD RDATA wire format is encoded as follows: 
qoa dq appa dgbqdqeme-em2259,3s 
0515223545590 8/0898208051]925305495262722859401152532455960 720899080] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Serial | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Scheme |Hash Algorithm | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Digest | 
/ / 
/ / 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


2.2.1. The Serial Field 
The Serial field is a 32-bit unsigned integer in network byte order. It is the serial number from 
the zone's SOA record ([RFC1035], Section 3.3.13) for which the zone digest was generated. 


It is included here to clearly bind the ZONEMD RR to a particular version of the zone's content. 
Without the serial number, a stand-alone ZONEMD digest has no obvious association to any 
particular instance of a zone. 

2.2.2. The Scheme Field 


The Scheme field is an 8-bit unsigned integer that identifies the methods by which data is 
collated and presented as input to the hashing function. 
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Herein, SIMPLE, with Scheme value 1, is the only standardized Scheme defined for ZONEMD 
records and it MUST be supported by implementations. The "ZONEMD Schemes" registry is 
further described in Section 5. 


Scheme values 240-254 are allocated for Private Use. 


2.2.3. The Hash Algorithm Field 


The Hash Algorithm field is an 8-bit unsigned integer that identifies the cryptographic hash 
algorithm used to construct the digest. 


Herein, SHA384 ([RFC6234]), with Hash Algorithm value 1, is the only standardized Hash 
Algorithm defined for ZONEMD records that MUST be supported by implementations. When 
SHA384 is used, the size of the Digest field is 48 octets. The result of the SHA384 digest algorithm 
MUST NOT be truncated, and the entire 48-octet digest is published in the ZONEMD record. 


SHA512 ([RFC6234]), with Hash Algorithm value 2, is also defined for ZONEMD records and 
SHOULD be supported by implementations. When SHA512 is used, the size of the Digest field is 64 
octets. The result of the SHA512 digest algorithm MUST NOT be truncated, and the entire 64-octet 
digest is published in the ZONEMD record. 


Hash Algorithm values 240-254 are allocated for Private Use. 
The "ZONEMD Hash Algorithms" registry is further described in Section 5. 


2.2.4. The Digest Field 


The Digest field is a variable-length sequence of octets containing the output of the hash 
algorithm. The length of the Digest field is determined by deducting the fixed size of the Serial, 
Scheme, and Hash Algorithm fields from the RDATA size in the ZONEMD RR header. 


The Digest field MUST NOT be shorter than 12 octets. Digests for the SHA384 and SHA512 hash 
algorithms specified herein are never truncated. Digests for future hash algorithms MAY be 
truncated but MUST NOT be truncated to a length that results in less than 96 bits (12 octets) of 
equivalent strength. 


Section 3 describes how to calculate the digest for a zone. Section 4 describes how to use the 
digest to verify the contents of a zone. 


2.3. ZONEMD Presentation Format 


The presentation format of the RDATA portion is as follows: 


* The Serial field is represented as an unsigned decimal integer. 
* The Scheme field is represented as an unsigned decimal integer. 
* The Hash Algorithm field is represented as an unsigned decimal integer. 


* The Digest is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is 
allowed within the hexadecimal text. 
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2.4. ZONEMD Example 


The following example shows a ZONEMD RR in presentation format: 


example.com. 86400 IN ZONEMD 2018031500 1 1 ( 
FEBESDACE2EC2FFA4BA99D46CD69D6D29711E55217057BEE 
7EB1A7B641A47BA7FED2DD5B97AE499FAFAA4F22C6BD647DE ) 


2.5. Including ZONEMD RRs in a Zone 


The zone operator chooses an appropriate hash algorithm and scheme and includes the 
calculated zone digest in the apex ZONEMD RRset. The zone operator MAY choose any of the 
defined hash algorithms and schemes, including the Private Use code points. 


The ZONEMD RRset MAY contain multiple records to support algorithm agility ([BCP201]). When 
multiple ZONEMD RRs are present, each MUST specify a unique Scheme and Hash Algorithm 
tuple. It is RECOMMENDED that a zone include only one ZONEMD RR, unless the zone operator is 
in the process of transitioning to a new scheme or hash algorithm. 


3. Calculating the Digest 


The algorithm described in this section is designed for the common case of offline DNSSEC 
signing. Slight deviations may be permitted or necessary in other situations, such as with 
unsigned zones or online DNSSEC signing. Implementations that deviate from the described 
algorithm are advised to ensure that it produces ZONEMD RRs, signatures, and denial-of- 
existence records that are identical to the ones generated by this procedure. 


3.1. Add ZONEMD Placeholder 


In preparation for calculating the zone digest(s), any existing ZONEMD records (and covering 
RRSIGs) at the zone apex are first deleted. 


Prior to calculation of the digest, and prior to signing with DNSSEC, one or more placeholder 
ZONEMD records are added to the zone apex. This ensures that denial-of-existence (NSEC, 
NSEC3) records are created correctly if the zone is signed with DNSSEC. If placeholders were not 
added prior to signing, the later addition of ZONEMD records would also require updating the 
Type Bit Maps field of any apex NSEC/NSEC3 RRs, which then invalidates the calculated digest 
value. 


When multiple ZONEMD RRs are published in the zone, e.g., during an algorithm rollover, each 
MUST specify a unique Scheme and Hash Algorithm tuple. 


It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of the Start of Authority 
(SOA). However, the TTL of the ZONEMD record may be safely ignored during verification in all 
cases. 


Wessels, et al. Standards Track Page 10 


КЕС 8976 DNS Zone Digest February 2021 


In the placeholder record, the Serial field is set to the current SOA Serial. The Scheme field is set 
to the value for the chosen collation scheme. The Hash Algorithm field is set to the value for the 
chosen hash algorithm. Since apex ZONEMD records are excluded from digest calculation, the 
value of the Digest field does not matter at this point in the process. 


3.2. Optionally, Sign the Zone 


Following the addition of placeholder records, the zone may be signed with DNSSEC. When the 
digest calculation is complete, and the ZONEMD record is updated, the signature(s) for the 
ZONEMD RRset MUST be recalculated and updated as well. Therefore, the signer is not required 
to calculate a signature over the placeholder record at this step in the process, but it is harmless 
to do so. 


3.3. Scheme-Specific Processing 


Herein, only the SIMPLE collation scheme is defined. Additional schemes may be defined in 
future updates to this document. 


3.3.1. The SIMPLE Scheme 


For the SIMPLE scheme, the digest is calculated over the zone as a whole. This means that a 
change to a single RR in the zone requires iterating over all RRs in the zone to recalculate the 
digest. SIMPLE is a good choice for zones that are small and/or stable, but it is probably not good 
for zones that are large and/or dynamic. 


Calculation of a zone digest requires RRs to be processed in a consistent format and ordering. 
This specification uses DNSSEC's canonical on-the-wire RR format (without name compression) 
and ordering as specified in Sections 6.1, 6.2, and 6.3 of [RFC4034] with the additional provision 
that RRsets having the same owner name MUST be numerically ordered, in ascending order, by 
their numeric RR TYPE. 


3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules 
When iterating over records in the zone, the following inclusion/exclusion rules apply: 


* All records in the zone, including glue records, MUST be included unless excluded by a 
subsequent rule. 


* Occluded data ([RFC5936], Section 3.5) MUST be included. 


* If there are duplicate RRs with equal owner, class, type, and RDATA, only one instance is 
included ([RFC4034], Section 6.3) and the duplicates MUST be omitted. 


* The placeholder apex ZONEMD RR(s) MUST NOT be included. 
* If the zone is signed, DNSSEC RRs MUST be included, except: 


* The RRSIG covering the apex ZONEMD RRset MUST NOT be included because the RRSIG will 
be updated after all digests have been calculated. 
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3.3.1.2. SIMPLE Scheme Digest Calculation 


A zone digest using the SIMPLE scheme is calculated by concatenating all RRs in the zone, in the 
format and order described in Section 3.3.1 subject to the inclusion/exclusion rules described in 
Section 3.3.1.1, and then applying the chosen hash algorithm: 


digest = hash( RR(1) | RR(2) | RR(3) | ... ) 


where "|" denotes concatenation. 


3.4. Update ZONEMD RR 


The calculated zone digest is inserted into the placeholder ZONEMD RR. Repeat for each digest if 
multiple digests are to be published. 


If the zone is signed with DNSSEC, the RRSIG record(s) covering the ZONEMD RRset MUST then be 
added or updated. Because the ZONEMD placeholder was added prior to signing, the zone will 
already have the appropriate denial-of-existence (NSEC, NSEC3) records. 


Some DNSSEC implementations (especially "online signing") might update the SOA serial number 
whenever a new signature is made. To preserve the calculated digest, generation of a ZONEMD 
signature MUST NOT also result in a change to the SOA serial number. The ZONEMD RR and the 
matching SOA MUST be published at the same time. 


4. Verifying Zone Digest 


The recipient of a zone that has a ZONEMD RR verifies the zone by calculating the digest as 
follows: 


Note: If multiple ZONEMD RRs are present in the zone, e.g., during an algorithm 
rollover, a match using any one of the recipient's supported Schemes and Hash 
Algorithms is sufficient to verify the zone. The verifier MAY ignore a ZONEMD RR if 
its Scheme and Hash Algorithm violates local policy. 


1. The verifier MUST first determine whether or not to expect DNSSEC records in the zone. By 
examining locally configured trust anchors and, if necessary, querying for and validating 
Delegation Signer (DS) RRs in the parent zone, the verifier knows whether or not the zone to 
be verified should include DNSSEC keys and signatures. For zones where signatures are not 
expected, or if DNSSEC validation is not performed, digest verification continues at step 4 
below. 


2. For zones where signatures are expected, the existence of the apex ZONEMD record MUST be 
validated. If the DNSSEC data proves the ZONEMD RRset does not exist, digest verification 
cannot occur. If the DNSSEC data proves the ZONEMD does exist, but is not found in the 
zone, digest verification MUST NOT be considered successful. 
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3. For zones where signatures are expected, the SOA and ZONEMD RRsets MUST have valid 
signatures, chaining up to a trust anchor. If DNSSEC validation of the SOA or ZONEMD RRsets 
fails, digest verification MUST NOT be considered successful. 

4. When multiple ZONEMD RRs are present, each MUST specify a unique Scheme and Hash 
Algorithm tuple. If the ZONEMD RRset contains more than one RR with the same Scheme and 
Hash Algorithm, digest verification for those ZONEMD RRs MUST NOT be considered 
successful. 


5. Loop over all apex ZONEMD RRs and perform the following steps: 


a. The SOA Serial field MUST exactly match the ZONEMD Serial field. If the fields do not 
match, digest verification MUST NOT be considered successful with this ZONEMD RR. 

b. The Scheme field MUST be checked. If the verifier does not support the given scheme, 
verification MUST NOT be considered successful with this ZONEMD RR. 

c. The Hash Algorithm field MUST be checked. If the verifier does not support the given hash 
algorithm, verification MUST NOT be considered successful with this ZONEMD RR. 

d. The Digest field size MUST be checked. If the size of the given Digest field is smaller than 12 
octets, or if the size is not equal to the size expected for the corresponding Hash Algorithm, 
verification MUST NOT be considered successful with this ZONEMD RR. 

e. The zone digest is computed over the zone data as described in Section 3.3 using the 
Scheme and Hash Algorithm for the current ZONEMD RR. 

f. The computed digest is compared to the received digest. If the two digest values match, 
verification is considered successful. Otherwise, verification MUST NOT be considered 
successful for this ZONEMD RR. 


Each time zone verification is performed, the verifier SHOULD report the status as either 
successful or unsuccessful. When unsuccessful, the verifier SHOULD report the reason(s) that 
verification did not succeed. 


5. IANA Considerations 


5.1. ZONEMD RRtype 


This document defines a new DNS RR type, ZONEMD, whose value 63 has been allocated by IANA 
from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) 
Parameters" registry: 


Type: ZONEMD 

Value: 63 

Meaning: Message Digest Over Zone Data 
Reference: [RFC8976] 
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5.2. ZONEMD Scheme 


IANA has created a new subregistry in the "Domain Name System (DNS) Parameters" registry as 
follows: 


Registry Name: ZONEMD Schemes 
Registration Procedure: Specification Required 
Reference: [RFC8976] 


Value Description Mnemonic Reference 
0 Reserved [RFC8976] 
1 Simple ZONEMD collation | SIMPLE [RFC8976] 


2-239 Unassigned 
240-254 Private Use N/A [RFC8976] 


255 Reserved [RFC8976] 
Table 1: ZONEMD Scheme Registry 


5.3. ZONEMD Hash Algorithms 


IANA has created a new subregistry in the "Domain Name System (DNS) Parameters" registry as 
follows: 


Registry Name: ZONEMD Hash Algorithms 
Registration Procedure: Specification Required 
Reference: [RFC8976] 


Value Description Mnemonic Reference 
0 Reserved [RFC8976] 
1 SHA-384 SHA384 [RFC8976] 
2 SHA-512 SHA512 [RFC8976] 


3-239 Unassigned 
240-254 Private Use N/A [RFC8976] 


255 Reserved [RFC8976] 
Table 2: ZONEMD Hash Algorithms Registry 
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6. Security Considerations 


6.1. Using Zone Digest without DNSSEC 


Users of ZONEMD with unsigned zones are advised that it provides no real protection against 
attacks. While zone digests can be used in the absence of DNSSEC, this only provides protection 
against accidental zone corruption such as transmission errors and truncation. When used in 
this manner, it effectively serves only as a checksum. For zones not signed with DNSSEC, an 
attacker can make any zone modifications appear to be valid by recomputing the Digest field of a 
ZONEMD RR. 


6.2. Attacks against the Zone Digest 


An attacker, whose goal is to modify zone content before it is used by the victim, may consider a 
number of different approaches. 


The attacker might perform a downgrade attack to an unsigned zone. This is why Section 4 talks 
about determining whether or not to expect DNSSEC signatures for the zone in step 1. 


The attacker might perform a downgrade attack by removing one or more ZONEMD records. 
Such a removal is detectable only with DNSSEC validation and is why Section 4 talks about 
checking denial-of-existence proofs in step 2 and signature validation in step 3. 


The attacker might alter the Scheme, Hash Algorithm, or Digest fields of the ZONEMD record. 
Such modifications are detectable only with DNSSEC validation. 


As stated in [BCP201], cryptographic algorithms age and become weaker as cryptanalysis 
techniques and computing resources improve with time. Implementors and publishers of zone 
digests should anticipate the need for algorithm agility on long timescales. 


6.3. Use of Multiple ZONEMD Hash Algorithms 


When a zone publishes multiple ZONEMD RRs, the overall security is only as good as the weakest 
hash algorithm in use. For this reason, Section 2 recommends only publishing multiple ZONEMD 
RRs when transitioning to a new scheme or hash algorithm. Once the transition is complete, the 
old scheme or hash algorithm should be removed from the ZONEMD RRset. 


6.4. DNSSEC Timing Considerations 


As with all DNSSEC signatures, the ability to perform signature validation of a ZONEMD record is 
limited in time. If the DS record(s) or trust anchors for the zone to be verified are no longer 
available, the recipient cannot validate the ZONEMD RRset. This could happen even if the 
ZONEMD signature is still current (not expired), since the zone's DS record(s) may have been 
withdrawn following a Key Signing Key (KSK) rollover. 
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For zones where it may be important to validate a ZONEMD RRset through its entire signature 
validity period, the zone operator should ensure that KSK rollover timing takes this into 
consideration. 


6.5. Attacks Utilizing ZONEMD Queries 


Nothing in this specification prevents clients from making, and servers from responding to, 
ZONEMD queries. Servers SHOULD NOT calculate zone digests dynamically (for each query) as 
this can be used as a CPU resource exhaustion attack. 


ZONEMD responses could be used in a distributed denial-of-service amplification attack. The 
ZONEMD RR is moderately sized, much like the DS RR. A single ZONEMD RR contributes 
approximately 65 to 95 octets to a DNS response for digest types defined herein. Other RR types, 
such as DNS Public Key (DNSKEY), can result in larger amplification effects. 


6.6. Resilience and Fragility 


ZONEMD is used to detect incomplete or corrupted zone data prior to its use, thereby increasing 
resilience by not using corrupt data, but also introduces some denial-of-service fragility by 
making good data in a zone unavailable if some other data is missing or corrupt. Publishers and 
consumers of zones containing ZONEMD records should be aware of these trade-offs. While the 
intention is to secure the zone data, misconfigurations or implementation bugs are generally 
indistinguishable from intentional tampering and could lead to service failures when 
verification is performed automatically. 


Zone publishers may want to deploy ZONEMD gradually perhaps by utilizing one of the Private 
Use hash algorithm code points listed in Section 5.3. Similarly, recipients may want to initially 
configure verification failures only as a warning, and later as an error after gaining experience 
and confidence with the feature. 


7. Performance Considerations 


This section is provided to make zone publishers aware of the performance requirements and 
implications of including ZONEMD RRs in a zone. 


7.1. SIMPLE SHA384 


As mentioned previously, the SIMPLE scheme may be impractical for use in zones that are either 
large or highly dynamic. Zone publishers should carefully consider the use of ZONEMD in such 
zones since it might cause consumers of zone data (e.g., secondary name servers) to expend 
resources on digest calculation. For such use cases, it is recommended that ZONEMD only be 
used when digest calculation time is significantly less than propagation times and update 
intervals. 
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The authors' implementation (Appendix B.1) includes an option to record and report CPU usage 
of its operation. The software was used to generate digests for more than 800 Top-Level Domain 
(TLD) zones available from [CZDS]. The table below summarizes the results for the SIMPLE 
scheme and SHA384 hash algorithm grouped by zone size. The Rate column is the mean amount 
of time per RR to calculate the digest, running on commodity hardware in early 2020. 


Zone Size (RRs) Rate (msec/RR) 


10-99 0.00683 

100 - 999 0.00551 

1000 - 9999 0.00505 

10000 - 99999 0.00602 
100000 - 999999 0.00845 
1000000 - 9999999 0.0108 
10000000 - 99999999 0.0148 


Table 3 


For example, based on the above table, it takes approximately 0.13 seconds to calculate a SIMPLE 
SHA384 digest for a zone with 22,000 RRs, and about 2.5 seconds for a zone with 300,000 RRs. 


These benchmarks attempt to emulate a worst-case scenario and take into account the time 
required to canonicalize the zone for processing. Each of the 800+ zones were measured three 
times and then averaged, with a different random sorting of the input data prior to each 
measurement. 


8. Privacy Considerations 


This specification has no impact on user privacy. 
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Appendix A. Example Zones with Digests 


This appendix contains example zones with accurate ZONEMD records. These can be used to 
verify an implementation of the zone digest protocol. Additional and more extensive test cases 
can be found via the ZONEMD Tests Wiki ([ZONE-DIGEST-TESTS]) maintained by the IETF DNSOP 
Working Group. 
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A.1. Simple EXAMPLE Zone 


Here, the EXAMPLE zone contains an SOA record, NS and glue records, and a ZONEMD record. 


example. 


ns1 
ns2 


Wessels, et al. 


86400 


86400 
86400 
86400 


3600 
3600 


IN 


IN 
IN 
IN 


IN 
IN 


SOA 
NS 


NS 
ZONEMD 


AAAA 


ns1 admin 2018031900 ( 
1800 900 604800 86400 ) 
ns1 

ns2 

2018031900 1 1 
c68090d90a7aed71 
6bc459f9340e3d7c 
1370d4d24b7e2fc3 
a1ddc0b9a87153b9 
a9713b3c9ae5cc27 
777198b8e730044c ) 
203.0.113.63 

2001 :db8: :63 
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A.2. Complex EXAMPLE Zone 


Here, the EXAMPLE zone contains duplicate RRs, an occluded RR, uppercase names, a wildcard, a 
multi-record RRset, a non-apex ZONEMD RR, and one out-of-zone RR. 


example. 86400 IN $0А ns1 admin 2018031900 ( 
1800 900 604800 86400 ) 
86400 IN NS ns1 
86400 IN NS ns2 
86400 IN ZONEMD 2018031900 1 1 ( 
a3b69bad980a3504 
elcffcb0fd6397f9 
3848071c93151f55 
2ae2f6b1711d4bd2 
d8b39808226d7b9d 
b71e34b72077f8fe ) 
ns1 3600 IN A 203.0.113.63 
NS2 3600 IN AAAA 2001 :db8::63 
occluded.sub 7200 IN TXT "I'm occluded but must be digested" 
sub 7200 IN NS ns1 
duplicate 300 IN TXT "I must be digested just once" 
duplicate 300 IN TXT "I must be digested just once" 
foo.test. 555 IN TXT "out-of-zone data must be excluded" 
UPPERCASE 3600 IN TXT "canonicalize uppercase owner names" 
* TIT IN PTR dont-forget-about-wildcards 
mail 3600 IN MX 20 MAIL1 
mail 3600 IN MX 10 Mail2.Example. 
sortme 3600 IN AAAA 2001 :db8::5:61 
sortme 3600 IN AAAA 2001:db8::3:62 
sortme 3600 IN AAAA 2001 :db8::4:63 
sortme 3600 IN AAAA 2001:db8::1:65 
sortme 3600 IN AAAA 2001 :db8::2:64 
non-apex 900 IN ZONEMD 2018031900 1 1 ( 
616c6c6f77656420 
6275742069676e6f 
7265642e20616c6c 
6f77656420627574 
2069676e6f726564 


2e20616c6c6f7765 ) 
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Here, the EXAMPLE zone contains multiple ZONEMD records. It has both SHA384 and SHA512 
digests using the SIMPLE scheme. It also includes ZONEMD records with Scheme and Hash 
Algorithm values in the private range (240-254). These additional private-range digests are not 


verifiable. 
example. 
example. 


example. 
example. 


example. 


example. 


example. 


ns1.example. 
ns2.example. 
NS2.EXAMPLE. 
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86400 


86400 
86400 
86400 


86400 


86400 


86400 


3600 
86400 
3600 


IN 


IN 
IN 
IN 


IN 


IN 


IN 


IN 
IN 
IN 


SOA 


NS 
NS 
ZONEMD 


ZONEMD 


ZONEMD 


ZONEMD 


ns1 admin 2018031900 ( 
1800 900 604800 86400 ) 


ns1.example. 
ns2.example. 
2018031900 1 1 ( 
62e6cf51b02e54b9 
b5f967d547ce4313 
6792901 f9f88e637 
493daaf401c92c27 
9dd10f0edb1c56f8 
080211f8480ee306 
2018031900 12 ( 
08cfa1115c7b948c 
4163а901270395еа 
226a930cd2cbcf2f 
a9a5e6eb85f37c8a 
4e114d884e66f176 
eab121cb02db7d65 
2e0cc4827e7a3204 
f166b47e5613fd27 
2018031900 1 240 
e2d523f654b9422a 
96c5a8f44607bbee 
2018031900 241 1 
e1846540e33a9e41 
89792d18d5d131f6 
05fc283e ) 
203.0.113.63 


"This example has multiple digests" 


2001 :db8::63 
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A.4. The URI.ARPA Zone 


The following sample zone is the URLARPA zone retrieved 2021-01-21. Note this sample zone has 
been re-signed with unpublished keys, so that the added ZONEMD RR also has a signature. 
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uri.arpa. 3600 IN SOA sns.dns.icann.org. ( 
noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) 
uri.arpa. 3600 IN RRSIG SOA 8 2 3600 ( 


uri 
uri 
uri 


UniS 
uri. 


uri 


uri. 


uri 


Uni 


uris 


Uri. 


uri 


uris 


Wessels, 


20210217232440 20210120232440 37444 uri.arpa. 
GzQw+QzwLDJr13REPGVmpEChjD1D2X1X0ie1DnWHpgaEw1E/dhs31CN3+B 
mHd4Kx3tffTRgiyq65HxR6feQ5v7VmAifjyXUYB1DZur1eP5qðMs2ygCB3 
byoeMgCNsFS10KZ2LdzNBRpy30ace8xQn1SpmHGfyrsgg+WbHKCT1dY= ) 
.arpa. 86400 IN NS a.iana-servers.net. 
.arpa. 86400 IN NS b.iana-servers.net. 
.arpa. 86400 IN NS c.iana-servers.net. 
arpa. 86400 IN NS ns2.lacnic.net. 

arpa. 86400 IN NS sec3.apnic.net. 

.arpa. 86400 IN RRSIG NS 8 2 86400 ( 
20210217232440 20210120232440 37444 uri.arpa. 
M-Iei21cewWGaMtkPlrhM9FpUAHXFKCHTVpeyrjxjEONeNgKtHZor5e4VA 
qJBOzNqo8go/qJpW1FBm-*T5Hn3asaBZVstFIYky38/C8UeRLPKq1hTTHAR 
YUlFrexr5fMtSUAVOgOQPSBfH3xBq/BgSccTdRb9clD*HE7djpqrLS4- ) 
arpa. 600 IN MX 10 pechora.icann.org. 
.arpa. 600 IN RRSIG MX 8 2 600 ( 
20210217232440 20210120232440 37444 uri.arpa. 
kQAJQivmv6A5hqYBK8h6Z13ESY69gmosXwKI6WEO9IS8RFetf rxr24ecdnY 
d@1pnDtgNNSoHkYRSOoB+C4+zuJsoyAAzGo9UOWMWj 97 /2xeGhf3PTC9me 
Q90hi6hul9By70R76XYmGhdWX8PBi60RUmZ1guslFBfQ8izwPqzuphs- ) 
arpa. 3600 IN DNSKEY 256 3 8 ( 
AwEAAbMxuFuLeVDuOWIMzYOTD/bTREjLf107wOi6ielJhqltEzgjNzmWJf 
9kGwwDmzxU7kbthMEhBNBZNn84zmcyRSCMzuStWveL7xmqqU1E3 swL8kLO 
vdZvc75XnmpHrk3ndTyEb6eZM7slh2C630h6K8VR5VkiZAkEGgOuZIT3Nj 
sF ) 

arpa. 3600 IN DNSKEY 257 3 8 
AwEAAdkTaWkZtZuRh7/OobBUFxM+ytTst+bCu@r9w+rEwXD7GbDs@pIMhM 
enrZzoAvmv1 fQxw2MGs6Ri6yPKFNULCFOSt918i6BVBLI+SKTY6XXeDUQp 
SEmSaxohHeRPMQFzpysf у xINp/L2rGtZ7yPmxY/XRiFPSO0myqwGJa9r06 
Zw9CHM5UDHKWV /E*zxPFq/I7CfPbrrzbUotBX7Ze6Vh3Sarllbe8cGUB2UF 
NaTRgwB@TwDBPRD5ER3w2Dzbr y9NhbE1T r7vV fhaGWeOGuqAUXw1XEg6Cr 
NkmJXJ2F 1Rzr9WHUzhp7uWxhAbmJREGf i2dEyPAbUAyC j BqhFaqglknvc= 
arpa. 3600 IN DNSKEY 257 3 8 ( 
AwEAAenQaBoFmDmvRT+/H5oNbm@T г 5FmNRNDEun@Jpj /ELkzeUr TWhNpQm 
ZelIMC81IOkZ185tEvOnRvn80vV39B17QIdrvvKGIh2HlgeDRCLolhaojfn2 
QMOeDStjF/WWHpxJOmE6CIuvhqYEU37yoJscGAPpPVPzNvnL1HhYTaao1VR 
YWQ/maMr J*bfHg*YX1N6M/8MnRjIKBif1FWjbCKvsn6dnuGGL90CWYUF J3 
Dwof XuhgPyZMkzPc88YkJ j 5EMvbMHAwtelbCwC-*ivx73210w/rXJn0ciQS 
OgoeVvDio8dIJmWQITWQAuP-*q/ZHFEFHPlrP3gvQh5mcVS48eLX71Bq7c- 
.arpa. 3600 IN RRSIG  DNSKEY 8 2 3600 ( 
20210217232440 20210120232440 12670 uri.arpa. 
DBE2gkKAoxJCfz47KKxzoImN/0AKArhIVHE7TyTwyODdRPo44V5R-*vL6th 
Ux1Q1CJi2Rw0jwAXymx5Y3Q873pOEllH-*4bJoITAdmoBmPXf YNW7C1vw9U 
PKHRPOigKHmCVwIeBYDTU3gfLcMTbRAnEWPDNOGXx1L1Mf7ITaC210abo79 
Ip3M/MR8IS3Vx/xZAZKKPHtLn3xUuJluPNanqJrED2gTs1L2xWZ1tqjsAjJ 
v7JnJo2HJ8XVRB5zBto01IaJ20oBlqcjdcQ/0V1yoM8uOy1pDwHQ2BJ17322 
gNMHBP9HSiUPIOaIDNUCwW8eUCcW6DIUk-s9u3GN1uTqwWzsYB/rA-- ) 
arpa. 3600 IN RRSIG  DNSKEY 8 2 3600 ( 
20210217232440 20210120232440 30577 uri.arpa. 
Kx6HwPAU1kGc1UZ7SERXtQj PajOF4iUvkwD;j 7MEG1xbQFB1KoJiEb/eiWO 
qmSWdIhMDv8myhgauejRLyJxwxz8HDRV4xOeHWnRGfWBkAXGYwke j VzOHz 
oIArVdUVRbr2JKigcTOoyFN-uu52cNB7hRYu7dH5y1h1c6UbOnzRpMtGxc 
gVyKQ-* / ARbIqGG3pegdEOvVA9wTPWEiyY65P2urghvnRg5ok/ jzwAdMx4X 
Gshiib70jq0sRV12ZIzj4rFgY/qsSO8SEXEhMo2VuSkoJNiofVzYoqpxEe 
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GnANKIT7Tx2xJL1BWyJxyc7E8Wr2QSgCcc* r YL6TkHDtJGHy7TaQ-- 

uri.arpa. 3600 IN ZONEMD 2018100702 1 1 
Odbc3c4dbfd75777c12ca19c337854b1577799901307c482e9d91d5d15 
cd934d16319d98e30c4201cf25a1d5a0254960 ) 

uri.arpa. 3600 IN RRSIG ZONEMD 8 2 3600 ( 
20210217232440 20210120232440 37444 uri.arpa. 
QDoAXZcL3HMyn8aAHyCUsu/Tqj4Gkth8xY1EqByOb8XOTwVtAAZNQORE 1 5 
iqNqjtJUbeJPtJSbLNqCL7rCq0CzNNnBscv6IIf4gnqJZjlGtHO300hXtK 
vEcAz7SU3IASsi6bB3nLmEAyERdYSeUGUBfx8vatQDIRhkgEnnWUTh4- ) 


uri.arpa. 3600 IN NSEC ftp.uri.arpa. ( 
NS SOA MX RRSIG NSEC DNSKEY ZONEMD ) 
uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 ( 


20210217232440 20210120232440 37444 uri.arpa. 

dU/rXLM/naWd1+1PiWiYVaNJyCkiuyZJSccr91pJ1673T8r3685B40DMYF 
afZRboVgwnl13ZrXddY6xOhZL3n9V9nxXZwj LJ2HJUo jFoKcXT1pnUyYUYv 
VQ2k j 4GHA06 f cGCEp5QFJ2KbCpeJoS*PhKGRRx28icCiNT4/uXQvO2E- ) 


ftp.uri.arpa. 604800 IN NAPTR 808 "" "" ( 
"1^ftp://([^:/?&]*) КО! ЛИ . ) 
ftp.uri.arpa. 604800 IN RRSIG МАРТЕ 8 З 604800 ( 


20210217232440 20210120232440 37444 uri.arpa. 

EygekDg1+Lyyq4NMSEpPyOr OywY f 9Y3FAB4v1DT44J3R5QGidaH817ZF jH 
oYFI8sY64iYOCV4sBnX/dh6C1L5NgpY+815065Xu3vvj yzbtuJ2k6YYwJr 
rCbv15DDn53zAhhO2hL9uLgyLraZGi9i7TFGd@sm3ZNyUF/EVL@CcxU= ) 


ftp.uri.arpa. 3600 IN NSEC http.uri.arpa. ( 
NAPTR RRSIG NSEC ) 
ftp.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 


20210217232440 20210120232440 37444 uri.arpa. 

pbPAKxevPXCu /bDqcvXiuBppXyFEmtHyiy0eAN5gS7mi6mp9Z9bWF у x /1 а 
H9+60FGYa5vGmJ5itu/4EDMe8iQeZbI8yrpM4TquB7RR/MGfBnTd8S+sjy 
Qt1RYG7yqEu77Vd78Fme22BKPJ+MVqj SQJHMUE / YUGomPkAjLJJwwGw- ) 


http.uri.arpa. 604800 IN МАРТЕ @0"" "" ( 
EAN теру Л ОЇ И УЖ pee SNNT HE БУ 
һїїр.иг1.агра. 604800 ТМ RRSIG NAPTR 8 3 604800 ( 


20210217232440 20210120232440 37444 uri.arpa. 

eTqbWvt1GvTeXozuvm4ebaAfkXFQKrtduOcEiExto80sHIiCbOOWL8UDa/ 
J3cDivtQca7LgUbOb6c17NESsrsVkc6zNPx5RK2tG7ZQYmhYmtqt fg10U5 
BRdHZ5TyqIXcHl1w9Blo2pir1Y9IQgshhD7UOGkbkEmvB1LrdOaHhAAg- ) 


http.uri.arpa. 3600 IN NSEC mailto.uri.arpa. ( 
NAPTR RRSIG NSEC ) 
http.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 


20210217232440 20210120232440 37444 uri.arpa. 

R9r1Nzw1CVz2N08q6DhULzcsuUmOUKcPaGAWEUAOt r81 j EDHSFHNM+khCd 
OI8nDstzA42aee4rwCEgijxJpRCcYOhrO1Ysrrr2fdqNz60JikMdarvU50 
0p0VXeaaJDf JQT44*0*YXaBwI7Qod3FTMx7aRib8i7istvPmlRr7ixA- ) 


mailto.uri.arpa. 604800 IN МАРТЕ SOP QS чч ү 
"I^mailto:(.*)0(.*)$!NM2!i" . ) 
mailto.uri.arpa. 604800 IN RRSIG МАРТЕ 8 3 604800 ( 


20210217232440 20210120232440 37444 uri.arpa. 

Ch2zTG2F1p1EvQPyIHA4Yd80XXL ј XOPvMbiqDjpJBcnCJsV8QF7krOwTLnU 
T3dB+asQud0 j PyzaHGwF 1Mzmr rAsszNAXAMJ6htDtFJdsgTMP /NkHhYRSm 
Vv6rLeAhd-*mVfObY12M//b/GGVTjeUI/gJaLWOfLVZxr1Fp5USCRjyw- ) 


mailto.uri.arpa. 3600 IN NSEC urn.uri.arpa. ( 
NAPTR RRSIG NSEC ) 
mailto.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 


20210217232440 20210120232440 37444 uri.arpa. 

fQUbSIE6E7JDi2rosah4SpCOTrKufeszFyj5YEavbQuY1Q5cNFvtm8KuE2 
XXMRgRIARGvM21eVqcoDw5hS3m2p0JL xH812WE72Y j YvWhvnwc5Rofe/8y 
B/vaSK9WCnqN8y2q6Vmy73AGPOfuiwmuBra7LlkOiqmyx3amSFizwms- ) 
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urn 


urn. 


urn. 
urn. 
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.uri.arpa. 604800 IN NAPTR ӨӨ "" "" ( 
SAUL TS TES БАН | o ENING ДНК о 
uri.arpa. 604800 IN RRSIG МАРТЕ 8 З 604800 ( 


20210217232440 20210120232440 37444 uri.arpa. 
CVt2Tgz0e5zmaSXqRfNys/80tVCk9nfPOzhezhN8Bo6MDt6yyKZ2kEEWJP 
jkN7PCYHjO8fG jnUnGAHZI2qBNv7PKHcpRA42VY03q927q85a65we001 YEO 
vPYMzACpua9TOtfNnynM2WsOuN9URXUyvYkXBdqOC81N3sx1dVELcwc- ) 
uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG NSEC 
uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 
20210217232440 20210120232440 37444 uri.arpa. 
JuKkMiC3/j9iM3V8/izcouXWAVGnSZ jkOgEgFPhutMqoy1QNRCSkbEZQzF 
K8B/PIVdzZF@Y5xk06zaKQj0zz60kSaNPIo1a7Vyy13wDY /uLCRRAHRJfp 
knuY70+AUNXVVVIEYJqZggd4k1/Rjh1GTZPYZTRrVid5eQidI1LqcOeg= ) 
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A.5. The ROOT-SERVERS.NET Zone 


The following sample zone is the ROOT-SERVERS.NET zone retrieved 2018-10-21. 


root-servers.net. 


root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 
root-servers. 


net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net: 
net. 
net. 
netr 


Ф 


заззнннюкюкечннеьноггашєа вә оосо о сссо 


.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
250O0;tSSenDnvelis- 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
ГОО Sel Velss- 
.Foot-servers. 
TOOL SSERVEIES. 
.root-servers. 
.root-servers. 
.root-servers. 
.root-servers. 
.root-servers. 
.root-servers. 
.root-servers. 
.root-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.root-servers. 
.root-servers. 
.Foot-servers. 
oot-servers.net. 


net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
Nets 
йел 
net. 
йе 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
ners 
nets 
net. 
net. 
net. 
net. 
net. 


3600000 IN SOA 


3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 
3600000 


IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 
IN 


NS 
NS 
NS 
NS 
NS 
NS 
NS 
NS 
NS 
NS 
NS 
NS 
NS 
AAAA 
A 

MX 
AAAA 
A 
AAAA 
A 
AAAA 
A 
AAAA 
A 
AAAA 
A 
AAAA 
A 
AAAA 
A 

MX 
AAAA 
A 
AAAA 
A 
AAAA 
A 
AAAA 
A 
AAAA 
A 
SOA 


February 2021 


a.root-servers.net. 
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) 


BPAY DqQ-hooloocoso 


m. 


.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
.Foot-servers. 
35 o0t- Servers. 
.Foot-servers. 
root-servers. 


net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 
net. 


2001:503:ba3e: :2:30 


198.41.0.4 
20 mail.isi 


.edu. 


2001:500:200::b 
199.9.14.201 


2001:500:2: 
192.33.4.12 


2001:500:2d: 


19977591 09 


2001:500:а8: 


192.203.230 


2001:500:2f: 


192.5.5.241 


2001:500:12: 


aC 
:d 
ге 
.10 
sf 
: ded 


1927 M2 36TA 
2001:500:1::53 
198.97.190.53 

10 mx.i.root-servers.org. 
2001:7fe::53 
192236148517 
2001:503:c27::2:30 
192.58.128.30 
2001:7fd::1 
193.0.14.129 
2001:500:9f::42 
199.7.83.42 
2001:dc3::35 
2025127227533 
a.root-servers.net. 


( 
nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) 


root-servers.net. 
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Appendix B. Implementation Status 


This section records the status of known implementations of the protocol defined by this 
specification at the time of publication, and is inspired by the concepts described in RFC 7942. 


Please note that the listing of any individual implementation here does not imply endorsement 
by the IETF. Furthermore, no effort has been spent to verify the information presented here that 
was supplied by IETF contributors. This is not intended as, and must not be construed to be, a 
catalog of available implementations or their features. Readers are advised to note that other 
implementations may exist. 


B.1. Authors' Implementation 


The authors have an open-source implementation in C, using the ldns library ([LDNS-ZONE- 
DIGEST]). This implementation is able to perform the following functions: 


* Read an input zone and output a zone with the ZONEMD placeholder. 

* Compute the zone digest over the signed zone and update the ZONEMD record. 
* Recompute DNSSEC signatures over the ZONEMD record. 

* Verify the zone digest from an input zone. 


This implementation does not: 


* Perform DNSSEC validation of the ZONEMD record during verification. 


B.2. Shane Kerr's Implementation 


Shane Kerr wrote an implementation of this specification during the IETF 102 hackathon ([ZONE- 
DIGEST-HACKATHON]). This implementation is in Python and is able to perform the following 
functions: 


* Read an input zone and output a zone with ZONEMD record. 
* Verify the zone digest from an input zone. 
* Output the ZONEMD record in its defined presentation format. 


This implementation does not: 


* Recompute DNSSEC signatures over the ZONEMD record. 
* Perform DNSSEC validation of the ZONEMD record. 
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B.3. NIC Chile Lab's Implementation 


NIC Chile Labs wrote an implementation of this specification as part of "dns-tools" suite ([DNS- 
TOOLS], which besides digesting, can also sign and verify zones. This implementation is in Go 
and is able to perform the following functions: 


* Compute zone digest over signed zone and update the ZONEMD record. 
* Verify the zone digest from an input zone. 

* Perform DNSSEC validation of the ZONEMD record during verification. 
* Recompute DNSSEC signatures over the ZONEMD record. 
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